Vike version updates that keep the leading digit (e.g. `0.4.x` => `0.4.y` or `1.x.y` => `1.z.w`) can be considered non-breaking except of `MINOR BREAKING CHANGES`.


## `MINOR BREAKING CHANGES`

[`MINOR BREAKING CHANGES`](https://github.com/vikejs/vike/blob/main/CHANGELOG.md#minor-breaking-changes) can be introduced in any version update, even patch updates (e.g. `1.2.3` => `1.2.4`).

They are expected to affect only very few users — you're unlikely to be one of them. So we recommend that you ignore `MINOR BREAKING CHANGES` unless updating breaks your app.

> If updating Vike breaks your app, check the [`CHANGELOG.md`](https://github.com/vikejs/vike/blob/main/CHANGELOG.md) for any `MINOR BREAKING CHANGES`. If you experience a breaking change that isn't listed then reach out — we'll treat it as a regression and fix it.

> Being able to introduce minor breaking changes in any version update allows us to *significantly* speed up Vike’s development.
>
> For example, it enables us to [quickly fix bugs](https://github.com/vikejs/vike/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22bug%20%3Aboom%3A%22): if Vike behaves incorrectly and fixing it helps almost everyone but breaks the app of very few users, then we prioritize the fix over strict adherence to non-breaking version updates.

## Semver

Vike doesn't strictly follow [semver](https://semver.org): features can be introduced in any version update.


## Deprecation warnings

Vike adds a warning when an API will be removed in the next major release.

> Adding a deprecation warning isn't a breaking change (it doesn't break your app) and, therefore, such warnings can be introduced in any version update.

You can migrate whenever you want — the old API and the new API are both supported until the next major release.
